Configurable metadata-based automation and content classification architecture for cloud-based collaboration platforms

ABSTRACT

Scalable architectures, systems, and services are provided herein for generating jobs by applying user-specified metadata rules to metadata events. More specifically, the scalable architecture described herein uses metadata to drive automations and/or polices in a cloud-based environment. In one embodiment, the architecture integrates a metadata service with an event-based automation engine to automatically trigger polices and/or automations based on metadata and/or changes in metadata changes. The metadata service can include customizable and/or pre-build metadata templates which can be used to automatically apply a metadata framework (e.g., particular fields) to files based on, for example, the upload or placement of a particular file in a particular folder. The architecture also provides for advanced metadata searching and data classification.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This present application is a continuation of U.S. patent applicationSer. No. 15/679,532, filed on Aug. 17, 2017, titled CONFIGURABLEMETADATA-BASED AUTOMATION AND CONTENT CLASSIFICATION ARCHITECTURE FORCLOUD-BASED COLLABORATION PLATFORMS,” which is a continuation of U.S.patent application Ser. No. 14/474,008, filed on Aug. 29, 2014, titled“CONFIGURABLE METADATA-BASED AUTOMATION AND CONTENT CLASSIFICATIONARCHITECTURE FOR CLOUD-BASED COLLABORATION PLATFORMS,” which is relatedto U.S. patent application Ser. No. 14/056,899 titled “CONFIGURABLEEVENT-BASED AUTOMATION ARCHITECTURE FOR CLOUD-BASED COLLABORATIONPLATFORMS,” filed on Sep. 13, 2013, the contents of which areincorporated by reference in their entireties.

BACKGROUND

As electronic and digital content use in enterprise settings and/orother organizational settings has become the preferred mechanism forproject, task, and work flow management, so has the need for streamlinedcollaboration and sharing of digital content and documents. In suchcollaboration environments, multiple users share, access, and otherwiseperform actions or tasks on content and files in shared workspaces.

When a user performs an action on a file in a collaboration environment,a corresponding job can be scheduled. For example, in response to a filebeing uploaded, the file might responsively be scanned. Currentautomation architectures for collaboration environments provide amechanism to kick off the jobs at the front-end (e.g., at the web orapplication servers). Unfortunately, these current architectures are noteasily scalable and do not provide for customizations of the jobs to beperformed responsive to particular actions in a distributed computingenvironment.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a diagram of an example system having a host serverof a cloud service and/or cloud storage accounts in a configurableevent-based automation architecture.

FIG. 2 depicts a diagram of an example web-based or online collaborationplatform deployed in an enterprise or other organizational setting fororganizing work items and workspaces, as one example of a hosted cloudservice and/or cloud storage accounts in a configurable event-basedautomation architecture.

FIG. 3 depicts a diagram of an example workspace in a cloud-based,online or web-based collaboration environment accessible by multiplecollaborators through various devices authorized to access the workspace.

FIG. 4 depicts a diagram illustrating an example event-based automationarchitecture for cloud-based collaboration platforms including auser-configurable back-end event-based automation engine.

FIG. 5 depicts a diagram illustrating an example metadata serviceengine.

FIG. 6 depicts a diagram illustrating an example event-based automationengine including a rule-based engine and a computing platform.

FIG. 7 depicts a block diagram illustrating example components of a rulemanager of a rule-based engine for automatically translating events intoone or more job requests based on user (or administrator) specifiedrules.

FIG. 8 depicts a block diagram illustrating example components of a jobmanager of a computing platform for queuing jobs and ensuring jobexecution.

FIG. 9 depicts a data flow diagram illustrating generation of a metadataevent, according to an embodiment.

FIG. 10 depicts a data flow diagram illustrating an example process forautomatically translating metadata events into one or more job requestsbased on user (or administrator) specified metadata rules, according toan embodiment.

FIG. 11 depicts a data flow diagram illustrating an example process forautomatically translating events into one or more job requests based onuser (or administrator) specified rules, according to an embodiment.

FIG. 12 depicts a flow diagram illustrating an example process forgenerating and storing a rule, according to an embodiment.

FIG. 13 depicts a flow diagram illustrating an example process forgenerating and storing a metadata rule, according to an embodiment.

FIG. 14 depicts a flow diagram illustrating an example process forqueuing jobs and ensuring job execution, according to an embodiment.

FIG. 15 depicts a diagram illustrating another example event-basedautomation engine including a rule-based engine and a computingplatform.

FIG. 16 depicts a diagrammatic representation of a machine in theexample form of a computer system within which a set of instructions,for causing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

The following description and drawings are illustrative and are not tobe construed as limiting. Numerous specific details are described toprovide a thorough understanding of the disclosure. However, in certaininstances, well-known or conventional details are not described in orderto avoid obscuring the description. References to one or an embodimentin the present disclosure can be, but not necessarily are, references tothe same embodiment; and such references mean at least one of theembodiments.

Reference in this specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the disclosure. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Moreover, various features aredescribed which may be exhibited by some embodiments and not by others.Similarly, various requirements are described which may be requirementsfor some embodiments but not other embodiments.

The terms used in this specification generally have their ordinarymeanings in the art, within the context of the disclosure, and in thespecific context where each term is used. Certain terms that are used todescribe the disclosure are discussed below, or elsewhere in thespecification, to provide additional guidance to the practitionerregarding the description of the disclosure. For convenience, certainterms may be highlighted, for example using italics and/or quotationmarks. The use of highlighting has no influence on the scope and meaningof a term; the scope and meaning of a term is the same, in the samecontext, whether or not it is highlighted. It will be appreciated thatsame thing can be said in more than one way.

Consequently, alternative language and synonyms may be used for any oneor more of the terms discussed herein, nor is any special significanceto be placed upon whether or not a term is elaborated or discussedherein. Synonyms for certain terms are provided. A recital of one ormore synonyms does not exclude the use of other synonyms. The use ofexamples anywhere in this specification including examples of any termsdiscussed herein is illustrative only, and is not intended to furtherlimit the scope and meaning of the disclosure or of any exemplifiedterm. Likewise, the disclosure is not limited to various embodimentsgiven in this specification.

Without intent to limit the scope of the disclosure, examples ofinstruments, apparatus, methods and their related results according tothe embodiments of the present disclosure are given below. Note thattitles or subtitles may be used in the examples for convenience of areader, which in no way should limit the scope of the disclosure. Unlessotherwise defined, all technical and scientific terms used herein havethe same meaning as commonly understood by one of ordinary skill in theart to which this disclosure pertains. In the case of conflict, thepresent document, including definitions will control.

Scalable architectures, systems, and services are provided herein forgenerating jobs by applying user-specified rules to various metadataevents. More specifically, the scalable architecture described hereinuses metadata to drive automations and/or polices in a cloud-basedenvironment.

In one embodiment, the architecture integrates a metadata service withan event-based automation engine to automatically trigger polices and/orautomations based on metadata and/or metadata changes. The metadataservice can include customizable and/or pre-build templates via atemplating system. The templates can be used to automatically apply ametadata framework (e.g., particular fields) to files based on, forexample, the upload or placement of a particular file in a particularfolder. The automation engine tracks the metadata and/or changes to themetadata and can responsively kick off jobs (e.g., notifications,policies, workflows, etc.). The architecture also provides for advancedmetadata searching and data classification. For example, when a useruploads a file and classifies it using metadata as highly confidential,this can trigger a particular policy or automation.

In one embodiment, the scalable architectures also facilitate supportfor a dynamic set of customizable metadata rules or conditions and jobdescriptions. The scalable architectures are distributed and faulttolerant.

Definitions:

Action: A user action can include, for example, file operation actionslike uploads or previews, as well as collaboration operations like taskassignment and comments. The user actions are logged by the action logframework.

Job: A job consists of asynchronous work that needs to be executed as aresult of an action. For example, a job can include notification to auser or conversion of a specific file. The jobs are described using aset of parameters specific to the work to be executed, as well as theaction log data of the event that triggered the job and any routinginformation required.

Rule: A rule defines what jobs are generated given a particular action.More than one rule can be triggered given an action and multiple jobscan be generated from a single rule.

Rule Manager: A rule manager is responsible for managing rules andapplying rules to incoming actions. The jobs generated are forwarded tothe job manager.

Job Manager: A job manager is responsible for tracking job statuses anddistributing work to worker machines.

Embodiments of the present disclosure describe an architecture includingsystems and methods for configurable event-based automation in acloud-based collaboration platform or environment.

FIG. 1 illustrates an example diagram of a system having a host server100 of a cloud service and/or cloud storage accounts in a configurableevent-based automation architecture.

The client devices 102 can be any system and/or device, and/or anycombination of devices/systems that is able to establish a connection,including wired, wireless, cellular connections with another device, aserver and/or other systems such as host server 100 and/or notificationserver 150. Client devices 102 will typically include a display and/orother output functionalities to present information and data exchangedbetween the devices 102 and/or the host server 100 and/or notificationserver 150.

For example, the client devices 102 can include mobile, hand held orportable devices or non-portable devices and can be any of, but notlimited to, a server desktop, a desktop computer, a computer cluster, orportable devices including, a notebook, a laptop computer, a handheldcomputer, a palmtop computer, a mobile phone, a cell phone, a smartphone, a PDA, a Blackberry device, a Treo, a handheld tablet (e.g. aniPad, a Galaxy, Xoom Tablet, etc.), a tablet PC, a thin-client, a handheld console, a hand held gaming device or console, an iPhone, and/orany other portable, mobile, hand held devices, etc. running on anyplatform or any operating system (e.g., Mac-based OS (OS X, iOS, etc.),Windows-based OS (Windows Mobile, Windows 7, etc.), Android, BlackberryOS, Embedded Linux platforms, Palm OS, Symbian platform. In oneembodiment, the client devices 102, host server 100, and app server 110are coupled via a network 106. In some embodiments, the devices 102 andhost server 100 may be directly connected to one another.

The input mechanism on client devices 102 can include touch screenkeypad (including single touch, multi-touch, gesture sensing in 2D or3D, etc.), a physical keypad, a mouse, a pointer, a track pad, motiondetector (e.g., including 1-axis, 2-axis, 3-axis accelerometer, etc.), alight sensor, capacitance sensor, resistance sensor, temperature sensor,proximity sensor, a piezoelectric device, device orientation detector(e.g., electronic compass, tilt sensor, rotation sensor, gyroscope,accelerometer), or a combination or variation of the above.

Signals received or detected indicating user activity at client devices102 through one or more of the above input mechanism, or others, can beused in the disclosed technology by various users or collaborators(e.g., collaborators 108) for accessing, through network 106, aweb-based collaboration environment or online collaboration platform(e.g., hosted by the host server 100).

The collaboration platform or environment hosts workspaces with workitems that one or more users can access (e.g., view, edit, update,revise, comment, download, preview, tag, or otherwise manipulate, etc.).A work item can generally include any type of digital or electroniccontent that can be viewed or accessed via an electronic device (e.g.,device 102). The digital content can include .pdf files, .doc, slides(e.g., Powerpoint slides), images, audio files, multimedia content, webpages, blogs, etc. A workspace can generally refer to any grouping of aset of digital content in the collaboration platform. The grouping canbe created, identified, or specified by a user or through other means.This user may be a creator user or administrative user, for example.

In general, a workspace can be associated with a set of users orcollaborators (e.g., collaborators 108) which have access to the contentincluded therein. The levels of access (e.g., based on permissions orrules) of each user or collaborator to access the content in a givenworkspace may be the same or may vary among the users. Each user mayhave their own set of access rights to every piece of content in theworkspace, or each user may have different access rights to differentpieces of content. Access rights may be specified by a user associatedwith a work space and/or a user who created/uploaded a particular pieceof content to the workspace, or any other designated user orcollaborator.

In general, the collaboration platform allows multiple users orcollaborators to access or collaborate efforts on work items such thateach user can see, remotely, edits, revisions, comments, or annotationsbeing made to specific work items through their own user devices. Forexample, a user can upload a document to a work space for other users toaccess (e.g., for viewing, editing, commenting, signing-off, orotherwise manipulating). The user can login to the online platform andupload the document (or any other type of work item) to an existingworkspace or to a new workspace. The document can be shared withexisting users or collaborators in a work space.

A diagrammatic illustration of the online collaboration environment andthe relationships between workspaces and users/collaborators areillustrated with further reference to the example of FIG. 2. Adiagrammatic illustration of a workspace having multiple work items withwhich collaborators can access through multiple devices is illustratedwith further reference to the example of FIG. 3.

In one embodiment, client devices 102 communicates with the host server100 and/or people search engine 150 over network 106. In general,network 106, over which the client devices 102, the host server 100,and/or people search engine 150 communicate, may be a cellular network,a telephonic network, an open network, such as the Internet, or aprivate network, such as an intranet and/or the extranet, or anycombination thereof. For example, the Internet can provide filetransfer, remote log in, email, news, RSS, cloud-based services, instantmessaging, visual voicemail, push mail, VoIP, and other services throughany known or convenient protocol, such as, but is not limited to theTCP/IP protocol, Open System Interconnections (OSI), FTP, UPnP, iSCSI,NSF, ISDN, PDH, RS-232, SDH, SONET, etc.

The network 106 can be any collection of distinct networks operatingwholly or partially in conjunction to provide connectivity to the clientdevices 102 and the host server 100 and may appear as one or morenetworks to the serviced systems and devices. In one embodiment,communications to and from the client devices 102 can be achieved by, anopen network, such as the Internet, or a private network, such as anintranet and/or the extranet. In one embodiment, communications can beachieved by a secure communications protocol, such as secure socketslayer (SSL), or transport layer security (TLS).

In addition, communications can be achieved via one or more networks,such as, but are not limited to, one or more of WiMax, a Local AreaNetwork (LAN), Wireless Local Area Network (WLAN), a Personal areanetwork (PAN), a Campus area network (CAN), a Metropolitan area network(MAN), a Wide area network (WAN), a Wireless wide area network (WWAN),enabled with technologies such as, by way of example, Global System forMobile Communications (GSM), Personal Communications Service (PCS),Digital Advanced Mobile Phone Service (D-Amps), Bluetooth, Wi-Fi, FixedWireless Data, 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, 3G LTE, 3GPP LTE,LTE Advanced, mobile WiMax, WiMax 2, WirelessMAN-Advanced networks,enhanced data rates for GSM evolution (EDGE), General packet radioservice (GPRS), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA,UMTS-TDD, 1×RTT, EV-DO, messaging protocols such as, TCP/IP, SMS, MMS,extensible messaging and presence protocol (XMPP), real time messagingprotocol (RTMP), instant messaging and presence protocol (IMPP), instantmessaging, USSD, IRC, or any other wireless data networks or messagingprotocols.

A diagrammatic illustration of the cloud-based environment (e.g.,collaboration environment) and the relationships between workspaces andusers/collaborators are illustrated with further reference to theexample of FIG. 2. A diagrammatic illustration of a workspace havingmultiple work items with which collaborators can access through multipledevices is illustrated with further reference to the example of FIG. 3.

In one embodiment, actions performed on work items or other activitiesthat occur in a workspace can be detected in real time or in near realtime. The host server can generate notifications or notification eventsfor one or more of the plurality of activities and select one or morerecipients for each notification. Various mechanisms or externalmessaging applications can then be used to notify users orcollaborators, including through the web interface to access thecollaboration platform, via email, and/or SMS, for example.

In one embodiment, the host server can comprise a distributed systemincluding both front-end and back-end components (systems). Although notshown, the host server can include an action log, an event dispatcher,one or more processors, one or more databases, and one or more real timeclients. Together these components are generally referred to herein asan “action log framework” (ALF). Components of the ALF may reside in thefront-end systems, the back-end systems, or a combination thereof.

In one embodiment, the event dispatcher (also referred to as the eventmanager dispatcher, see e.g., FIG. 14), accumulates events anddispatches and/or otherwise distributes the events to one or more rulemanagers. As described herein, the event-based automation engineincludes a rule-based engine to automatically translate each event intoone or more jobs based on user-specified rules (e.g.,administrator-specified rules) and the job manager

FIG. 2 depicts a diagram of a web-based or online collaboration platformdeployed in an enterprise or other organizational setting 250 fororganizing work items 215, 235, 255 and workspaces 205, 225, 245, as oneexample of a hosted cloud file sharing, collaboration service and/orcloud storage service in a configurable event-based automationarchitecture.

The web-based platform for collaborating on projects or jointly workingon documents can be used by individual users and shared amongcollaborators. In addition, the collaboration platform can be deployedin an organized setting including but not limited to, a company (e.g.,an enterprise setting), a department in a company, an academicinstitution, a department in an academic institution, a class or coursesetting, or any other types of organizations or organized setting.

When deployed in an organizational setting, multiple workspaces (e.g.,workspace A-N) may be created to support different projects or a varietyof work flows. Each workspace may have its own associate work items. Forexample, work space A 205 may be associated with work items 215, workspace B 225 may be associated with work items 235, and work space N maybe associated with work items 255. The work items 215, 235, and 255 maybe unique to each work space but need not be. For example, a particularword document may be associated with only one work space (e.g., workspace A 205) or it may be associated with multiple work spaces (e.g.,work space A 205 and work space B 225, etc.).

In general, each work space has a set of users or collaboratorsassociated with it. For example, work space A 205 is associated withmultiple users or collaborators 206. In some instances, work spacesdeployed in an enterprise may be department specific. For example, workspace B may be associated with department 210 and some users shown asexample user A 208 and workspace N 245 may be associated withdepartments 212 and 216 and users shown as example user B 214.

Each user associated with a work space may generally access the workitems associated with the work space. The level of access may depend onpermissions associated with the specific work space, and/or with aspecific work item. Permissions may be set for the work space or setindividually on a per work item basis. For example, the creator of awork space (e.g., one of user A 208 who creates work space B) may setone permission setting applicable to all work items 235 for otherassociated users and/or users associated with the affiliate department210, for example. Creator user A 208 may also set different permissionsettings for each work item, which may be the same for different users,or varying for different users.

In each work space A, B, . . . , N, when an action is performed on awork item by a given user or any other activity is detected in the workspace, other users in the same work space may be notified (e.g., in realtime or in near real time, or not in real time). Activities whichtrigger real time notifications can include, by way of example but notlimitation, adding, deleting, or modifying collaborators in the workspace, uploading, downloading, adding, deleting a work item in the workspace, and creating a discussion topic in the work space.

In some embodiments, items or content (content items) downloaded oredited in accordance with the techniques described in the presentdisclosure can cause notifications to be generated. Such notificationscan be sent to relevant users to notify them of actions surrounding adownload, an edit, a change, a modification, a new file, a conflictingversion, an upload of an edited or modified file. Additionally, asdiscussed above, actions performed on the content items can bemaintained by an ALF system.

In one embodiment, in a user interface of the web-based collaborationplatform where notifications are presented, users can, via the userinterface, create action items (e.g., tasks) and delegate the actionitems to other users including collaborators pertaining to a work item215, for example. The collaborators 206 may be in the same workspace A205 or the user may include a newly invited collaborator. Similarly, inthe same user interface where discussion topics can be created in a workspace (e.g., work space A, B or N, etc.), actionable events on workitems can be created and/or delegated/assigned to other users such ascollaborators of a given work space 206 or other users. Through the sameuser interface, task status and updates from multiple users orcollaborators can be indicated and reflected. In some instances, theusers can perform the tasks (e.g., review or approve or reject, etc.)via the same user interface.

FIG. 3 depicts an example diagram of a workspace 302 in an online orweb-based collaboration environment accessible by multiple collaborators322 through various devices authorized to access the work space.

Each of users 316, 318, and 320 may individually use multiple differentdevices to access and/or manipulate work items 324 (e.g., content items)in the work space 302 with which they are associated with. For example,users 316, 318, 320 may be collaborators on a project to which workitems 324 are relevant. Since the work items 324 are hosted by thecollaboration environment (e.g., a cloud-based environment), each usermay access the work items 324 anytime, and from any physical locationusing any device (e.g., including devices they own or anyshared/public/loaner device).

Work items to be edited or viewed may be accessed from the workspace 302in accordance with the platform and/or application independentmechanisms. Users may also be notified of access, edit, modification,and/or upload related-actions performed on work items 324 by other usersor any other types of activities detected in the work space 302. Forexample, if user 316 modifies a document, one or both of the othercollaborators 318 and 320 can be notified of the modification in realtime, or near real-time, or not in real time. The notifications can besent through any of all of the devices associated with a given user, invarious formats including, one or more of, email, SMS, or via a pop-upwindow in a user interface in which the user uses to access thecollaboration platform. In the event of multiple notifications, eachnotification may be depicted preferentially (e.g., ordering in the userinterface) based on user preferences and/or relevance to the user (e.g.,implicit or explicit).

For example, a notification of a download, access, read, write, edit, orupload related activities may be presented in a feed stream among othernotifications through a user interface on the user device according torelevancy to the user determined based on current or recent activity ofthe user in the web-based collaboration environment.

In one embodiment, a notification feed stream includes updates when aninvited user accepts an invitation and/or successfully creates a newaccount through receipt of an invitation from an existing user. Theinvited user, upon creation of the new account, receives the accounthaving enhanced features. The new user can automatically be connected tothe existing user who sent the invitation. The system can alsoautomatically prompt both users to query who they wish to becollaborators in a common work space.

Work items hosted by a collaboration environment (e.g., a cloud-basedcollaboration environment) can be accessed by users (e.g., users 316,318, and 320) via multiple different devices (e.g., devices 304-314) forviewing, editing, processing or performing other manipulations on workitems. The devices can include applications for accessing a serverhosting a cloud-based platform or service or other back-end web services(hereinafter “cloud-based collaboration platform application”) andapplications for viewing, editing, processing, or performing othermanipulations on work items. The communication between such applicationsare generally facilitated by a communication mechanism of the OS. Forexample, in Android OS, the communication mechanism is based on“Intents”. As previously described, the underlying communicationmechanism is generally insecure, and any data passed betweenapplications is visible to all other applications on a device.

FIG. 4 depicts a diagram illustrating an example event-based automationarchitecture 400 for a cloud-based collaboration platform 405 includinga user-configurable back-end event-based automation engine 430 and ametadata service engine 450. As shown, the event-based automationarchitecture 400 can include various client (or user or administer)systems 410 and the cloud-based collaboration platform 405. Notably, asillustrated and discussed in the example of FIG. 4, placement of theevent-based automation engine 430 is in the back-end of the cloud-basedarchitecture providing scalability in the architectural design.

In one embodiment, the cloud-based collaboration platform 405 caninclude the host server 100 and/or the notification server 150 ofFIG. 1. The cloud-based collaboration platform 405 can include variousfront-end system(s) and back-end system(s) that can be physically and/orfunctionally distributed. As shown, the cloud-based collaborationplatform 405 includes front-end system 420 (e.g., a web server), aback-end even-based automation engine 430, various data warehouse(s)440, and a metadata service engine 450. The client systems 410 can beconfigured to communicate via the network 406 a with the front-endsystem(s) 420. Similarly, the front-end system(s) 420 can be configuredto communicate with the client or user system(s) 410 and the event-basedautomation engine 430 via the network 406 b, and the event-basedautomation engine 430 can be configured to communicate with thefront-end system(s) 420 via the network 406 b and the data warehouses440.

Additionally, in some embodiments, an administrator system 410 can beconfigured to bypass the front-end systems in order to directly submit ajob, determine the status of a job, kill a job, etc. via a web interfaceor application program interface built into the event-based automationengine 430. In some embodiments, clients, users and/or administratorscan access the metadata service engine 450 in order to select,configure, and/or generate templates or provide input for metadatasearching.

In one embodiment, the front-end system(s) 420 can include various webapplications and/or web servers. Additionally, in some embodiments, thefront-end system(s) 420 can provide ALF events to the event-basedautomation engine 430. As discussed in greater detail with reference toFIG. 6, the back-end event-based automation engine 430 can include arule-based engine and a computing platform. The rules based engine canbe configured to generate and manage user-defined (or specified) rulesand apply the rules to incoming ALF events. The computing platformincludes a jobs manager configured to generate jobs based on jobrequests, track the job statuses, and distribute work to workers. Thevarious components, functions, and or tools that can be associated withand/or included within an event-based automation engine are discussed ingreater detail with reference to FIG. 6.

In one embodiment, the rules-based engine can be configured to generateand manage user-defined (or specified) metadata rules and apply themetadata rules to metadata events generated by the metadata serviceengine 450. As described in greater detail with reference to FIG. 5, themetadata service engine 450 monitors metadata (e.g., job requests,events, actions, etc.) to identify changes to metadata. The metadataevents can be generated responsive to these metadata changes. Asdescribed herein, the metadata service engine 450 can provide theability to generate and/or select templates for providing a metadataframework to particular work items. Additionally, the metadata serviceengine 450 provides the ability to search metadata in the cloud-basedenvironment.

FIG. 5 depicts a diagram illustrating an example metadata service engine500. The metadata service engine 500 can be the metadata service engine450 of FIG. 4, although alternative configurations are possible. Asshown in the example of FIG. 5, the metadata service engine includes anadministrator/user interface 515, a templating in engine 520, a templatedatabase 525, a metadata event generation engine 530, a metadata chancedetection engine 540, a metadata monitoring engine 550, a metadatasearch engine 560, and a metadata rules interface 570. The templatingengine 520 includes a template selection engine 522, template generationengine 524, and a template configuration engine 526.

Additional or fewer components/modules/engines can be included in themetadata service engine 500 and/or in each illustratedcomponent/module/engine. Further, although illustrated as included aspart of the metadata service engine 500, the components/modules/enginesand/or the template databases 525 can be physically and/or functionallydistributed.

One embodiment of the metadata service engine 500 includes theadministrator/user interface 515. The administrator/user interface 515can comprise any interface configured to facilitate receiving andprocessing of templating inputs for selection, configuration, and/orgeneration of metadata templates. For example, the administrator/userinterface 515 can include a network interface having a networking modulethat enables the metadata service engine 500 to mediate data in anetwork with an entity that is external to the metadata service engine500, through any known and/or convenient communications protocolsupported by the host and the external entity. The network interface caninclude one or more of a network adaptor card, a wireless networkinterface card (e.g., SMS interface, WiFi interface, interfaces forvarious generations of mobile communication standards including but notlimited to 1G, 2G, 3G, 3.5G, 4G, LTE, etc.,), Bluetooth, a router, anaccess point, a wireless router, a switch, a multilayer switch, aprotocol converter, a gateway, a bridge, a bridge router, a hub, adigital media receiver, and/or a repeater.

Additionally, the administrator/user interface 515 can comprise anyinterface configured to facilitate receiving of metadata search input.As discussed below, the administrator/user interface 515 interacts withthe metadata search engine 560 to provide users and/or administratorsthe ability to search by metadata.

One embodiment of the metadata service engine 500 includes thetemplating engine 520. The templating engine 520 can includecustomizable and/or pre-build metadata templates which can be used toautomatically apply a metadata framework (e.g., particular fields) tofiles (or work items) based on, for example, the upload or placement ofa particular file in a particular folder, selection of those files by auser or administrator, and/or in other manners discussed herein or knownin the art. As discussed above, the templating engine 520 includes atemplate selection engine 522, template generation engine 524, and atemplate configuration engine 526. The template selection engine 522 isconfigured to select one or more pre-configured templates forapplication of those templates to work items in the cloud-basedcollaborative environment. The template generation engine 524 and atemplate configuration engine 526 are configured to generate andconfigure metadata templates responsive to the templating input. One ormore template database(s) 525 persistently stores the templates in thecloud-based collaborative environment.

One embodiment of the metadata service engine 500 includes the metadataevent generation engine 530, the metadata chance detection engine 540,and the metadata monitoring engine 550. The metadata monitoring engine550 monitors actions, events, jobs, job requests, etc. to identifychanges to metadata occurring to work items within the collaborativecloud-based environment. The metadata change detection engine 540detects these changes to the metadata and the metadata event generationengine 530 responsively generates the metadata events.

One embodiment of the metadata service engine 500 includes the metadatasearch engine 560. The metadata search engine 560 is configured tofacilitate searching of the metadata in the collaborative cloud-basedenvironment. In some embodiments, the metadata search engine 560 canindex the metadata. For example, the metadata search engine 560collects, parses, and stores data to facilitate fast and accuratemetadata information retrieval.

One embodiment of the metadata service engine 500 includes the metadatarules interface 570. The metadata rules interface 570 is configured tointeract with the rules engine to, for example, automatically providerules to be generated based on configurations/customizations of metadatatemplates.

FIG. 6 depicts a diagram illustrating example event-based automationengine 600 including a rule-based engine and a computing platform. Theevent-based automation engine 600 can be the event-based automationengine 430 of FIG. 4, although alternative configurations are possible.As shown in the example of FIG. 6, the rules-based engine includes anaction log 605, an administrator interface 610, a rule manger 620, and arule database 625. The computing platform includes a directionapplication program interface (API) 630, a jobs manager 620, multiplestorage databases 645 and 646, and multiple workers 650A-N.

The rule manager 620 can include any system and/or service that isconfigured to receive incoming ALF events and/or metadata events andapply rules (or metadata rules) to the events to automatically generatecorresponding job requests and send the job requests to the jobs manager640. The administrator interface 610 allows administrative users togenerate (or set) rules or metadata rules which are then stored, by therule manager 620, in the rules database 625. An example rules manager isdiscussed in greater detail with reference to FIG. 7.

The jobs manager 640 can, among other functions, receive job requestsfrom the rule manager, generate jobs corresponding to job requests,determine relevant queues for jobs, route jobs to relevant queues forperformance by workers, and track and/or otherwise monitor the status ofeach of the jobs. In addition to supporting content workflow, the jobmanager is also intended to be a general-purpose job system that canprovide asynchronous job execution for other services. An example jobsmanager is discussed in greater detail with reference to FIG. 8. Theworkers 650A-N can comprise distributed machines or computers in one ormore computer clusters.

FIG. 7 depicts a block diagram illustrating example components of a rulemanager 700 of a rule-based engine. The rule manager 700 can beconfigured to automatically translate ALF events into one or more jobrequests based on user (or administrator) specified rules. The rulemanager 700 can be, for example, rule manager 620 of FIG. 6, althoughalternative configurations are possible.

The rule manager 700 can include an administrator interface 705, a rulegeneration/definition engine 710, an action/event interface 715, ametadata event interface 716, a parsing engine 720, a rulematching/section engine 730, and a job request generation engine 740.The parsing engine 720 can include an event type parser 622, anenterprise identifier (ID) parser 624, and a metadata identificationmodule 726. As shown in the example of FIG. 7, the rule manager 700 alsoincludes a rules database (DB) 750 and a metadata rules database (DB)755.

Additional or fewer components/modules/engines can be included in therule manager 700 and/or in each illustrated component/module/engine.Further, although illustrated as included as part of the rule manager700, the components/modules/engines and/or the rules database 750 and/orthe metadata rules database 755 can be physically and/or functionallydistributed.

One embodiment of the rule manager 700 includes the administratorinterface 705. The administrator interface 705 can comprise anyinterface configured to facilitate setting and/or generation of theuser-defined rules by an administer. For example, the administratorinterface 705 can include a network interface having a networking modulethat enables the rule manager 700 to mediate data in a network with anentity that is external to the rule manager 700, through any knownand/or convenient communications protocol supported by the host and theexternal entity. The network interface can include one or more of anetwork adaptor card, a wireless network interface card (e.g., SMSinterface, WiFi interface, interfaces for various generations of mobilecommunication standards including but not limited to 1G, 2G, 3G, 3.5G,4G, LTE, etc.,), Bluetooth, a router, an access point, a wirelessrouter, a switch, a multilayer switch, a protocol converter, a gateway,a bridge, a bridge router, a hub, a digital media receiver, and/or arepeater.

One embodiment of the rule manager 700 includes the rulegeneration/definition engine 710. The rule generation/definition engine710 facilitates rule generation/definition by users or administrators.For example, users can define rules in a rule descriptive language (RDL)that can be automatically triggered and executed by the rule manager.The users or administrators can also define metadata rules in a similarmatter. Alternatively or additionally, metadata rules can beautomatically generated and input into the system based onuser-generated or pre-existing metadata templates defined by themetadata service engine 500.

Each rule can include one or more conditions that can be determined bythe user and/or automatically by the system. Each condition isassociated with a job. In operation, when a condition is evaluated to betrue, the associated job is triggered and/or otherwise generated.Metadata rules can be defined in a similar fashion. Alternatively oradditionally, metadata rules can be defined based on keys of key valuepairs. In some embodiments, threshold or defined values for the metadatakey-value pairs can be set that trigger the rule. For example, if themetadata template defines a contract, then one metadata attribute may bethe value of the contract. A rule can be set that triggered a particularaction or job in the event that the value of the contract exceeds aparticular preset value. For instance, one or more notifications may besent to particular individuals for review. Similarly, a metadataattribute of a contract template could include a status attribute thatcauses a particular action or job to be performed when the value of thekey-value pair change from ‘PENDING’ to ‘APPROVED’. In this manner,metadata or changes to metadata can trigger job requests (e.g., eventsor actions).

One embodiment of the rule manager 700 includes the action/eventinterface 715. The action/event interface 715 can receive eventsincluding ALF events. For example, the action/event interface 715 canreceive events from an action log dispatcher (ALD) (also referred to asa dispatcher or an event manager dispatcher herein). In one embodiment,the ALD accumulates and distributes actions taken and logged bycollaborators in the collaboration environment. The distributed eventscan be, for example, ALF events that indicate the user actions taken oncontent items in the web applications. The ALD can accumulate anddistribute and/or otherwise provide sets of ALF events (e.g., multipleevents) to the rule manager simultaneously. For example, in oneembodiment, the ALF events can be distributed via an action such as, forexample, action log 605 of FIG. 6.

One embodiment of the rule manager 700 includes the metadata eventinterface 716. The metadata event interface 716 can receive metadataevents. For example, the metadata event interface 716 can receivemetadata events from a metadata service engine such as, for example,metadata service engine 500 of FIG. 5. The metadata events can identifya change in a metadata key-value pair associated with a particular workitem in the collaborative cloud-based environment. For example, acontract (work item) can include a metadata key-value pair including akey: value of contract and a value of that key: monetary value.

One embodiment of the rule manager 700 includes the parsing engine 720.The parsing engine 720 parses each of the events to identify eventcriteria associated with the event such as, for example, an action typeand/or an enterprise identifier (ID). The parsing engine 720 can alsoparse and/or otherwise process the metadata events and identify therelevant information such as, for example, the associated key-valuepair.

The example rule manger 700 of FIG. 7 is shown including an event typeparser 722, an enterprise ID parser 724, and a metadata identificationmodule 726; however, it is appreciated that other (any) criteria can beparsed from the event (or metadata events) via the parsing engine 720.

One embodiment of the rule manager 700 includes the rulematching/selection engine 730. The rule matching/selection engine 730 isconfigured to access pre-defined rules from the rules database 750, andscan the pre-defined rules to select pre-defined rules that matchparticular event criteria. For example, the rule manger 700 can utilizefilters (or criteria) to select or match ALF events with rules. Examplefilters include, but are not limited to, enterprise_id, all_enterprises,all_users, and event type. Additionally, the rule matching/selectionengine 730 can parse the metadata rules to select pre-defined rules thatmatch a particular key and/or value of a key value pair associated witha particular metadata event.

In one embodiment, the rule matching/selection engine 730 includes arule parser 732, a metadata rules parser 734, and a classificationmodule 736. The rule parser 732 is configured to parse the rules toidentify one or more conditions associated with the rule and thecorresponding job descriptions (also referred to herein as jobtemplates) that are triggered if the condition occurs. The jobdescriptions are embedded in the rules and define the job to beperformed. For example, each job indicates a process or type of workthat is to be performed by one of the workers (e.g., distributedprocessing machines).

The metadata rule parser 734 is configured to parse the metadata rulesto identify one or more keys and or values that match the key-value pairassociated with the metadata event. For example, the metadata ruleparser 734 can determine a pre-defined metadata rule that matches thekey of the key-value pair.

One embodiment of the rule manager 700 includes the job requestgeneration engine 740. The job request generation engine 740 isconfigured to generate one or more job requests for each rule. Forexample, in one embodiment, the job request generation engine 740generates a job request based on each job description (or job template)corresponding to each rule condition. As discussed above, the jobsindicate work to be performed by workers (e.g., workers 650 of FIG. 6).The job request generation engine 740 is also configured to processkey-value pairs associated with the metadata events to conditionallygenerate job requests (e.g., if the rule is triggered). For example, thejob request generation engine 740 can determine a value of the metadatakey-value pair associated with a particular work item, process the firstpre-defined metadata rule that matches the key of the key-value pair,identify a threshold value associated with the first pre-definedmetadata rule and compare the value of the metadata key-value pair withthe threshold value. The job request can then be generated if the ruleis triggered. That is, the job request can be conditionally generatedbased on the comparison.

FIG. 8 depicts a block diagram illustrating example components of a jobmanager 800 of a computing platform for generating, queuing, andensuring job execution. The job manager 800 can, among other functions,route jobs to relevant queues 860 for performance by workers and trackand/or otherwise monitor the status of each of the jobs. The job manager800 can be, for example, job manager 640 of FIG. 6, although alternativeconfigurations are possible.

The job manager 800 can include an administrator interface 805, a jobsinterface 810, a leader election engine 815, an error detection engine820, a status engine 825, a retry engine 830, a replication engine 840,a job scheduler 850, and various queues 860. As shown in the example ofFIG. 8, the job manager 800 also includes storage databases 842 and 844,although these database can be considered as distinct in someembodiments. Additional or fewer components/modules/engines can beincluded in the rule manager 800 and/or in each illustratedcomponent/module/engine. Further, although illustrated as included aspart of the jobs manager 800, the components/modules/engines and/or thestorage databases 842 and 844 can be physically and/or functionallydistributed.

One embodiment of the jobs manager 800 includes the administratorinterface 805. The administrator interface 805 can comprise anyinterface (e.g., a web interface) configured to facilitate directadministrator access for job submission, job status, or killing of jobs.In one embodiment, the administrator interface 805 can include a networkinterface having a networking module that enables the jobs manager 800to mediate data in a network with an entity that is external to the jobsmanager 800, through any known and/or convenient communications protocolsupported by the host and the external entity. The network interface caninclude one or more of a network adaptor card, a wireless networkinterface card (e.g., SMS interface, WiFi interface, interfaces forvarious generations of mobile communication standards including but notlimited to 1G, 2G, 3G, 3.5G, 4G, LTE, etc.,), Bluetooth, a router, anaccess point, a wireless router, a switch, a multilayer switch, aprotocol converter, a gateway, a bridge, a bridge router, a hub, adigital media receiver, and/or a repeater.

One embodiment of the jobs manager 800 includes the jobs interface 810.The jobs interface 810 can receive jobs including batched jobs. Asdiscussed above, the jobs indicate work to be performed by workers(e.g., workers 650 of FIG. 6).

One embodiment of the jobs manager 800 includes the jobs interfaceleader election engine 815. As described herein, multiple instances ofthe job manager can be utilized in a distributed environment to preventdata loss and facilitate scalability. The leader election engine 815 canbe used to guarantee that only one instance of the job manager 800 isperforming operations so that the operations are not duplicated. Forexample, in one embodiment, the leader election engine 815 is utilizedto ensure that only one service in each cluster is retrying and/orreplicating jobs.

One embodiment of the jobs manager 800 includes the error detectionengine 820. For example, the error detection engine 820 can provideinfinite loop detection. That is, in some cases, users/admins cangenerate rules that create an infinite loop such as, for example:

Rule 1: Condition/Job

-   -   If a file is uploaded/moved to folder A/move file to folder B;

Rule 2: Condition/Job

-   -   If a file is moved to folder B/move file to folder A.

In one embodiment, the error detection engine 820 prevents suchscenarios by injecting a unique token into the worker initiated APIrequests. The token flows through the API and web app and back into theALF stream with the associated event. The rule manager can then pass thetoken along to the job manager where the job manager prevents jobs frombeing queued if the token had been seen too many times. Otherwise, thetoken would be added to the new job and the workers would need to reusethe token when executing the job.

One embodiment of the jobs manager 800 includes the status engine 825.The status engine 825 can track and/or otherwise monitor the status ofjobs submitted to the queues. The status engine 825 ensures that jobsare executed. In one embodiment, jobs and status updates (started,completed, failed) are persisted in a local database (e.g., the localHBase cluster). The status engine 825 also responds to status queriesreceived at the administrator interface (or web interface).

In one embodiment, status or progress cache is maintained by the jobmanager. The status or progress cache can provide status and/or progressupdates (i.e., 10%, 20%, etc.) of jobs completed to interested clients(administrators). Additionally, as discussed above, the job managersupports an API or administer interface for receiving these updates fromthe workers and then providing the details to clients via a job statusquery response. In one embodiment, because of the temporary nature ofthe updates, rather than storing the updates in HBase, the job managerwill store them in memcache.

One embodiment of the jobs manager 800 includes the replication engine840. The replication engine 840 can save or store the jobs to first andsecond databases 842 and 844. Each database can comprise an HBase atgeographically remote data centers. As described in more detail below,once the job is stored in multiple data centers, the job manager 800 canthen respond to the rule manager (e.g., acknowledge the reception of thejobs).

One embodiment of the jobs manager 800 includes the job scheduler 850.The job scheduler 850 can generate jobs based on the job requests anddetermine the appropriate queues 860 for the jobs and distributes thejobs to the appropriate queues. In one embodiment, the appropriatequeues 860 are selected based on the type of job. That is, particularqueues can be designed for and serviced by workers that are specificallyconfigured to perform those jobs. By way of example and not limitation,the system can designate dedicated queues for the following jobs:preview jobs, video conversion jobs, text extraction jobs, virus scanjobs, thumbnail creation jobs, data loss prevention (DLP) jobs, etc.Alternatively or additionally, one or more general purpose queues couldbe utilized by one or more general purpose workers (i.e., workersconfigured to perform a variety of different types of jobs).

FIG. 9 depicts a data flow diagram illustrating an example process 900for generation of a metadata event, according to an embodiment. Ametadata service engine such as, for example, the metadata data serviceengine 500 of FIG. 5 can, among other functions, perform the exampleprocess 900. The metadata service engine may be embodied as hardwareand/or software, including combinations and/or variations thereof. Inaddition, in some embodiments, the metadata service engine can includeinstructions, wherein the instructions, when executed by one or moreprocessors, cause the one or more processors to perform one or moreprocesses including the following processes.

To begin, in process 910, the metadata service engine monitors changesin metadata. For example, the metadata service engine can monitor jobrequests, changed work items, events, actions, etc. in order to identifychanges or potential changes to metadata within the collaborativecloud-based environment. In process 912, the metadata service enginedetermines if a change in the metadata is detected. The change in themetadata can be, for example a change in a metadata key-value pair.

If a change is detected in process 912, the metadata service engineoptionally, in process 914, determines if the metadata is associatedwith a predetermined metadata template. For example, in some instances,the metadata service engine only monitors a subset of the metadata(e.g., metadata for which rules have been established and/or metadataassociated with a defined metadata template). In process 916, themetadata service engine generates the metadata event. In someembodiments, the metadata event can be optionally generated based onwhether the metadata or changed metadata is associated with a definedmetadata template.

FIG. 10 depicts a data flow diagram illustrating an example process 1000for automatically translating metadata events into one or more jobrequests based on user (or administrator) specified metadata rules,according to an embodiment. A rule manager such as, for example, rulemanager 700 of FIG. 7, can, among other functions, perform the exampleprocess 1000. The rule manager may be embodied as hardware and/orsoftware, including combinations and/or variations thereof. In addition,in some embodiments, the rule manager can include instructions, whereinthe instructions, when executed by one or more processors, cause the oneor more processors to perform one or more processes including thefollowing processes.

To begin, in process 1010, the rule manager receives a metadata eventand, in process 1012, processes the metadata event to identify orcapture an associated key-value pair. As discussed above, the metadataevent can be an event that is initiated by a metadata service engineresponsive to monitoring changes in metadata in content items in thecollaborative cloud-based environment.

In process 1014, the rule manager scans the metadata rules based on themetadata key and, at decision process 1016, determines if the metadatakey matches a metadata rule. In one embodiment, the rule manger can alsoscan the metadata rules for other conditions or values that are comparedto the value of the key-value to make a determination about whether ametadata rule is triggered or if a metadata event matches a rule.

In process 1018, the rule manager selects a metadata rule that matchesthe metadata event, if one exists. Next, in process 1020, the rulemanager identifies a job description associated with the selectedmetadata rule. For example, the job description can indicate the type ofjob that is to be performed when the rule is triggered. Lastly, inprocess 1022, the rule manager generates a new job request based on thejob description. As discussed herein, the rule manager distributes thebatched jobs to the jobs manager. In some embodiments, load balancersmay be used to distribute events to multiple instances of the rulemanager and jobs to multiple instances of the job manager, respectively.Additionally, the instances referred to herein are referring toadditional distributed hardware resources.

FIG. 11 depicts a data flow diagram illustrating an example process 1100for automatically translating events into one or more job requests inone or more back-end systems based on user (or administrator) specifiedrules, according to an embodiment. A rule manager such as, for example,rule manager 700 of FIG. 7, can, among other functions, perform theexample process 1100. The rule manager may be embodied as hardwareand/or software, including combinations and/or variations thereof. Inaddition, in some embodiments, the rule manager can includeinstructions, wherein the instructions, when executed by one or moreprocessors, cause the one or more processors to perform one or moreprocesses including the following processes.

To begin, in process 1110, the rule manager receives an event and, inprocess 1112, parses the event to identify event criteria. As discussedabove, the event can be an ALF event that is initiated by a webapplication (e.g., front-end system) responsive to an action taken on acontent item in the collaborative cloud-based environment.

In process 1112, the rule manager parses the event to identify eventcriteria. For example, the event criteria can include an action type(i.e., type of action performed that triggered the event, e.g., upload)or an enterprise identifier.

In process 1114, the rule manager scans the rules based on the eventcriteria and, at decision process 1116, determines if the event matchesa rule. In one embodiment, the rule manger can also scan the rules forconditions that are compared to the event criteria to determine if anevent matches a rule. In process 1118, the rule manager selects a rulethat matches the event criteria, if one exists. Next, in process 1120,the rule manger identifies a job description associated with theselected rule. For example, the job description can indicate the type ofjob that is to be performed.

In process 1122, the rule manager generates a new job request based onthe job description and, in process 1124, waits for additional new jobsto be generated to batch multiple job requests. Lastly, in process 1126,the rule manager distributes the batched jobs to the jobs manager. Asdiscussed below with reference to FIG. 11, in some embodiments, loadbalancers may be used to distribute events to multiple instances of therule manager and jobs to multiple instances of the job manager,respectively. Additionally, the instances referred to herein arereferring to additional distributed hardware resources.

FIG. 12 depicts a flow diagram illustrating an example process 1200 forgenerating and storing a user-defined rule, according to an embodiment.A rule manager such as, for example, rule manager 700 of FIG. 7, can,among other functions, perform the example process 1200. The rulemanager may be embodied as hardware and/or software, includingcombinations and/or variations thereof. In addition, in someembodiments, the rule manager can include instructions, wherein theinstructions, when executed by one or more processors, cause the one ormore processors to perform one or more processes including the followingprocesses.

To begin, in process 1210, the rule manager receives information from anadminister for defining a new rule. In one embodiment, the informationincludes a user defined condition and a corresponding job definition.For example, the condition “on file upload into folder A” can bereceived from the administrator with a corresponding job “move the fileinto folder B.” As discussed above, the user-defined (or pre-defined)rules can be applied to incoming events (e.g., ALF events) toautomatically generate jobs to be performed by workers in a computingplatform.

In one embodiment, the rule manager can extract various additionalconditions and/or job descriptions based on, for example, the type ofcondition. This is referred to herein as a complex rule. For example, ifthe condition “on file upload” is received with the job description“scan file,” then the system can extract various jobs to perform insequence: extract text, scan file for keyword, and quarantine file ifkeyword found.

In process 1212, the rule manager generates the rule by associatingcondition(s) with the corresponding job description(s) and, lastly, inprocess 1214, the rule is stored in a rule database.

FIG. 13 depicts a flow diagram illustrating an example process 1300 forgenerating and storing a metadata rule, according to an embodiment. Arule manager such as, for example, rule manager 700 of FIG. 7, can,among other functions, perform the example process 1300. The rulemanager may be embodied as hardware and/or software, includingcombinations and/or variations thereof. In addition, in someembodiments, the rule manager can include instructions, wherein theinstructions, when executed by one or more processors, cause the one ormore processors to perform one or more processes including the followingprocesses.

To begin, in process 1310, the rule manager receives information from anadministrator for defining a new metadata rule. In one embodiment, theinformation identifies an associated template and/or a key value formetadata. Additionally, the information can also include a thresholdvalue for the key that causes the rule to be triggered. For example, ifthe metadata template defines a contract, then one metadata attribute orkey may be the value of the contract. A rule can be set that triggered aparticular action or job in the event that the value of the contractexceeds a particular preset value. For instance, one or morenotifications may be sent to particular individuals for review.Similarly, a metadata attribute of a contract template could include astatus attribute that causes a particular action or job to be performedwhen the value of the key-value pair change from ‘PENDING’ to‘APPROVED’. In this manner, metadata or changes to metadata can triggerjob requests (e.g., events or actions).

In process 1312, the rule manager generates the metadata rule byassociating the metadata key with additional information (e.g., templateand/or threshold value) and with one or more corresponding jobdescription(s) and, lastly, in process 1314, the metadata rule is storedin a rule database.

FIG. 14 depicts a flow diagram illustrating an example process 1400 forqueuing jobs and ensuring job execution, according to an embodiment. Ajobs manager such as, for example, jobs manager 800 of FIG. 8, can,among other functions, perform the example process 1400. The jobsmanager may be embodied as hardware and/or software, includingcombinations and/or variations thereof. In addition, in someembodiments, the rule manager can include instructions, wherein theinstructions, when executed by one or more processors, cause the one ormore processors to perform one or more processes including the followingprocesses.

To begin, in process 1410, the jobs manager receives a job initiated bythe rule manager and, in process 1412, stores the job persistently inone or more data centers. In one embodiment, the jobs manager stores thejob in multiple remote data centers at least one of which isgeographically remote.

In process 1413, the jobs manager generates jobs responsive to the jobrequests and, in process 1414, the jobs manager determines anappropriate queue for the job. In one embodiment, the appropriate queuesare selected based on the type of job. That is, particular queues can bedesigned for and serviced by workers that are specifically configured toperform those jobs. By way of example and not limitation, the system candesignate dedicated queues for the following jobs: preview jobs, videoconversion jobs, text extraction jobs, virus scan jobs, thumbnailcreation jobs, data loss prevention (DLP) jobs, etc. Alternatively oradditionally, one or more general purpose queues could be utilized byone or more general purpose workers (i.e., workers configured to performa variety of different types of jobs).

In process 1416, the jobs manager distributes the job to the appropriatequeue and, lastly, in process 1418, the jobs manager maintains thecurrent status of the job. As described in more detail with reference toFIG. 15, status updates (e.g., started, completed, failed) can bepersisted to the local HBase cluster.

FIG. 15 depicts a diagram illustrating another example event-basedautomation engine 1500 including a rule-based engine and a computingplatform. As shown in the example of FIG. 15, the rule based engineincludes an event manager dispatcher, an event load balancer, multiplerule managers, a job load balancer, multiple job managers, multiplerabbitMQ queues, and multiple workers. Additionally, a MySQL database isshown in communication with the multiple rule managers for storing therules, a zookeeper distributed services system is shown in communicationwith the rule managers and the job managers as part of the distributedsystem to help coordinate various different services includingcoordination and distribution of new rules. Further, an HBase storagedatabase is shown at a local data center and a second HBase storagedatabase is replicated at a remote data center (i.e., remote from thefirst data center).

The rule manager is responsible for translating events it receives fromthe Action Log Dispatcher (ALD) (or Event Manager Dispatcher) into jobrequests depending on a set of customer specified rules. For example, ifa file is uploaded to a certain folder, a task could be automaticallycreated and assigned to a user for that file. More specifically, therule manager generates jobs for content workflow based on the ALFstream. Importantly, incoming events are not acknowledged until jobs arepersisted to Hbase and, thus, the rule matching and job generation stephas low latency. In addition, the rules are user-defined and, thus, anynumber of rules can be defined. The rule manager can scale (i.e., withadditional instances) with the increasing number of rules.

In one embodiment, events are distributed from an ALF system via the ALDservice. The ALD can send a request containing a set of events to therule manager. Each event can be described as an action log. Thus, foreach action log, the rule manager can parse out the action_type andenterprise_id and then scan for rules matching the action_type andenterprise_id against its local cache.

In one embodiment, the rules are defined using a Rule DescriptionLanguage (RDL) which can be parsed by the rule manager to extract thefilters and job template. For example, rules can have an optional set ofsimple conditional filters such as, for example, “=” by which to filterout jobs to avoid the need to send no-op jobs to the job manager. Thefilters work by comparing data extracted from the action log againstpredefined static values. For job creation, rules can include a templatejob description that the rule manager can populate using data from theaction log. The filled out template is essentially a serialized jobbody.

Once the events in the current request from the ALD are evaluated, therule manager can forward the generated jobs to the job manager. The rulemanager will receive an acknowledgement from the job manager and send anacknowledgement back to the ALD. If no jobs are created from a requestfrom the ALD, then the rule manager will simply acknowledge the requestimmediately.

The job manager is a component of content workflow that receives jobrequests from the rule manager. In addition to supporting contentworkflow, the job manager is also intended to be a general-purpose jobsystem that can provide asynchronous job execution for other services.The job manager is generally responsible for creating new jobs andmonitoring the status of jobs. The job manager essentially ensures thata job will be executed. As discussed above, new jobs and status updates(e.g., started, completed, failed) can be persisted to the local HBasecluster.

In one embodiment, when the job manager receives a new job request, itfirst persistently stores the job to HBase. Once the job has been savedto HBase, the job manager will acknowledge the job request and therebyguarantee the execution of the job. After the job manager hasacknowledged the job request, the job manager will then queue the job inRabbitMQ for execution. Workers actively pick up jobs off the queue andexecute these jobs.

In one embodiment, prior to queuing the job, the job manager can injectcallbacks into the job description to be notified by a worker before itbegins executing a job, after it finishes executing a job, and/or if anerror occurs during execution. To handle temporary errors, the jobmanager uses an actor to periodically re-queue jobs that have not beenstarted or completed after a configurable amount of time. The jobmanager also has an actor that is dedicated to replicating to the remoteHBase cluster on a configurable interval.

As illustrated in the example of FIG. 15, in one embodiment, the jobmanagers receive requests from behind the job load balancer, whichdistributes requests between multiple job manager instances. In oneembodiment, each instance runs a Jetty Web Server and Scalatra that arebundled in box-common. These services are used to handle communicationto the job manager including receiving requests for new jobs and alsofor status updates from workers.

In one embodiment, each request to the rule manager can contain a batchof requests. The jobs (job requests) sent from the rule manager to thejob manager can also be batched. In some embodiments, a single requestfrom the rule manager will contain all the jobs that should be generatedfor a request from the action log dispatcher (ALD). A single event fromthe dispatcher and, thus, spawn a group of jobs (e.g., FILE_UPLOAD)could trigger virus scanning and text extraction jobs. The job managerresponds to a request by indicating, for each group of jobs, whether theentire group of jobs is guaranteed to be run. When an incoming jobrequest is written to HBase, it is at that point “guaranteed” by the jobmanager. This guarantee will be reflected in the response. Additionally,the web interface scales horizontally by deploying additional serverswith the job manager service.

In one embodiment, rule updates are performed through the rule managerweb application. For example, the web application can perform CRUDoperations on rules using the DB_Model framework. For the rule managerto keep its internal cache (or database) of rules in sync with the webapplication rule changes, the web application can insert an event intothe ALF stream for every change to the rules. The rule manager processesall ALF events at least once, and thus, the rule manager identifies therule update event and can responsively update the version in Zookeeperto notify all subscribing rule manager instances to update their localcaches (rule databases).

In one embodiment, the rule manager utilizes RDL to describe rules. TheRDL includes syntax for facilitating translation of an action to a job.In one embodiment, each rule has a rule description defined using RDL.The following snippet illustrates the basic structure of an RDL rule:

{ “rdl_version”: <int> // what version of the RDL are we using“rule_id”: <int> // id of the rule. Useful for reporting/debugging“action_log_version”: <int> // what version of the action was thiswritten against “job”: { /** * Template of the job body that would beforwarded to the job manager. * See jobs for more **/ } “filter”: { //filters we need to apply before job creation. see filters for more } }

In one embodiment, rules are stored in a MySQL database. However, anadditional index table can allow the rule manager to quickly filterrules by enterprise id and action type. An example Rules Search IndexTable Schema and the associated Rules Table Schema follow.

Rules Search Index Table Schema:

-   -   rule_search_index_id—primary id    -   rule_id—foreign key to g_box_content_workflow_rules    -   action_type_id—id of the type of action that occurred    -   enterprise_id—id of the enterprise for which to apply this rule    -   (this field is set to 0 if there is no such specific enterprise)    -   all_enterprises—boolean of whether the rule applies to all        enterprise users. If this is true, enterprise_id is set to 0.    -   all_users—boolean of whether the rule applies to all users. If        this is true, enterprise_id is set to 0.    -   created—timestamp of when the rule_search_index was created    -   updated—timestamp of when the rule_search_index was updated    -   deleted—timestamp of when the rule_search_index was deleted

And an example Rules Table Schema:

-   -   rule_id—primary id    -   description—description of the rule specified in RDL    -   created—timestamp of when the rule was created    -   updated—timestamp of when the rule was updated    -   deleted—timestamp of when the rule was deleted

To prevent conflicts of fields used to filter rules aside fromaction_type_id, only one field from the set of these “filter fields”(enterprise_id, allEnterprises, allUsers) is used. Examples of validvalues for the “filter fields” include, but are not limited to:

-   -   Rule applies to all enterprise actions:        -   enterprise_id=0;allEnterprises=true;allUsers=false    -   Rule applies to actions from enterprise 32:        -   enterprise_id=32;allEnterprises=false;allUsers=false    -   Rule applies to all users (free+enterprise):        -   enterprise_id=0;allEnterprises=false;allUsers=true

In one embodiment, the rule manager also supports a ruleset. Forexample, rules that form part of a logical workflow can be groupedtogether into a ruleset. In this case, a ruleset_id is included with theRules Template Table Schema. Users can interact with this feature fromthe UI.

In one embodiment, rules are cached in-memory of the rule managerinstance. As discussed above, these local caches of all rule managerinstances are synchronized via versioning in Zookeeper.

In one embodiment, the rule manager supports the following basicanalysis of rules:

-   -   1. Given an event, find all rules that will be applied;    -   2. Given an event, list all jobs generated;

The service can also be set up with a secondary index that will allowaggregation counts of the kinds of rules or jobs present in the system.

In one embodiment, the rule manager supports templating. Templatingincludes the process of allowing the rule manager to populate fieldsfrom the action log into a given field or position in the job template.The fields can reference any field in the API event object.

In one embodiment, the rule manager supports versioning. Versioningallows the rule manager to check the action log version and the RDLversion to determine if an incoming action log data can be successfullyapplied. For user-defined filters, only fields in the official EventsAPI can be referenced. The rule manager is responsible for ensuringfields in the Events API are correctly extracted from action log data.This means that the rule manager is responsible for maintainingbackwards compatibility.

In one embodiment, the rule manager supports permission control. Thatis, requests to the rule manager must be authenticated.

FIG. 16 illustrates a diagrammatic representation of a machine 1600 inthe example form of a computer system within which a set ofinstructions, for causing the machine to perform any one or more of themethodologies discussed herein, may be executed.

In alternative embodiments, the machine operates as a standalone deviceor may be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aclient machine in a client-server network environment, or as a peermachine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personalcomputer (PC), a user device, a tablet PC, a laptop computer, a set-topbox (STB), a personal digital assistant (PDA), a cellular telephone, aniPhone, an iPad, a Blackberry, a processor, a telephone, a webappliance, a network router, a switch or bridge, a console, a hand-heldconsole, a (hand-held) gaming device, a music player, any portable,mobile, hand-held device, or any machine capable of executing a set ofinstructions (sequential or otherwise) that specify actions to be takenby that machine.

While the machine-readable medium or machine-readable storage medium isshown in an exemplary embodiment to be a single medium, the term“machine-readable medium” and “machine-readable storage medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” and “machine-readable storage medium” shallalso be taken to include any medium that is capable of storing, encodingor carrying a set of instructions for execution by the machine and thatcause the machine to perform any one or more of the methodologies of thepresently disclosed technique and innovation.

In general, the routines executed to implement the embodiments of thedisclosure, may be implemented as part of an operating system or aspecific application, component, program, object, module or sequence ofinstructions referred to as “computer programs.” The computer programstypically comprise one or more instructions set at various times invarious memory and storage devices in a computer, and that, when readand executed by one or more processing units or processors in acomputer, cause the computer to perform operations to execute elementsinvolving the various aspects of the disclosure.

Moreover, while embodiments have been described in the context of fullyfunctioning computers and computer systems, those skilled in the artwill appreciate that the various embodiments are capable of beingdistributed as a program product in a variety of forms, and that thedisclosure applies equally regardless of the particular type of machineor computer-readable media used to actually effect the distribution.

Further examples of machine-readable storage media, machine-readablemedia, or computer-readable (storage) media include, but are not limitedto, recordable type media such as volatile and non-volatile memorydevices, floppy and other removable disks, hard disks, optical disks(e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks,(DVDs), etc.), among others, and transmission type media such as digitaland analog communication links.

The network interface device enables the machine 1600 to mediate data ina network with an entity that is external to the host server, throughany known and/or convenient communications protocol supported by thehost and the external entity. The network interface device can includeone or more of a network adaptor card, a wireless network interfacecard, a router, an access point, a wireless router, a switch, amultilayer switch, a protocol converter, a gateway, a bridge, a bridgerouter, a hub, a digital media receiver, and/or a repeater.

The network interface device can include a firewall which can, in someembodiments, govern and/or manage permission to access/proxy data in acomputer network, and track varying levels of trust between differentmachines and/or applications. The firewall can be any number of moduleshaving any combination of hardware and/or software components able toenforce a predetermined set of access rights between a particular set ofmachines and applications, machines and machines, and/or applicationsand applications, for example, to regulate the flow of traffic andresource sharing between these varying entities. The firewall mayadditionally manage and/or have access to an access control list whichdetails permissions including, for example, the access and operationrights of an object by an individual, a machine, and/or an application,and the circumstances under which the permission rights stand.

Other network security functions can be performed or included in thefunctions of the firewall, can be, for example, but are not limited to,intrusion-prevention, intrusion detection, next-generation firewall,personal firewall, etc. without deviating from the novel art of thisdisclosure.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof, means any connection or coupling,either direct or indirect, between two or more elements; the coupling ofconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, shall referto this application as a whole and not to any particular portions ofthis application. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

As used herein, a “module,” “a manager,” a “handler,” a “detector,” an“interface,” or an “engine” includes a general purpose, dedicated orshared processor and, typically, firmware or software modules that areexecuted by the processor. Depending upon implementation-specific orother considerations, the module, manager, handler, or engine can becentralized or its functionality distributed. The module, manager,handler, or engine can include general or special purpose hardware,firmware, or software embodied in a computer-readable (storage) mediumfor execution by the processor. As used herein, a computer-readablemedium or computer-readable storage medium is intended to include allmediums that are statutory (e.g., in the United States, under 35 U.S.C.§ 101), and to specifically exclude all mediums that are non-statutoryin nature to the extent that the exclusion is necessary for a claim thatincludes the computer-readable (storage) medium to be valid. Knownstatutory computer-readable mediums include hardware (e.g., registers,random access memory (RAM), non-volatile (NV) storage, to name a few),but may or may not be limited to hardware.

The above detailed description of embodiments of the disclosure is notintended to be exhaustive or to limit the teachings to the precise formdisclosed above. While specific embodiments of, and examples for, thedisclosure are described above for illustrative purposes, variousequivalent modifications are possible within the scope of thedisclosure, as those skilled in the relevant art will recognize. Forexample, while processes or blocks are presented in a given order,alternative embodiments may perform routines having steps, or employsystems having blocks, in a different order, and some processes orblocks may be deleted, moved, added, subdivided, combined, and/ormodified to provide alternative or subcombinations. Each of theseprocesses or blocks may be implemented in a variety of different ways.Also, while processes or blocks are at times shown as being performed inseries, these processes or blocks may instead be performed in parallel,or may be performed at different times. Further, any specific numbersnoted herein are only examples: alternative implementations may employdiffering values or ranges.

The teachings of the disclosure provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various embodiments described above can be combined toprovide further embodiments.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the disclosure can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further embodiments of thedisclosure.

These and other changes can be made to the disclosure in light of theabove Detailed Description. While the above description describescertain embodiments of the disclosure, and describes the best modecontemplated, no matter how detailed the above appears in text, theteachings can be practiced in many ways. Details of the system may varyconsiderably in its implementation details, while still beingencompassed by the subject matter disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the disclosure should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the disclosure with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the disclosure to the specific embodimentsdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe disclosure encompasses not only the disclosed embodiments, but alsoall equivalent ways of practicing or implementing the disclosure underthe claims.

While certain aspects of the disclosure are presented below in certainclaim forms, the inventors contemplate the various aspects of thedisclosure in any number of claim forms. For example, while only oneaspect of the disclosure is recited as a means-plus-function claim under35 U.S.C. § 112, ¶6, other aspects may likewise be embodied as ameans-plus-function claim, or in other forms, such as being embodied ina computer-readable medium. (Any claims intended to be treated under 35U.S.C. § 112, ¶6 will begin with the words “means for”.) Accordingly,the applicant reserves the right to add additional claims after filingthe application to pursue such additional claim forms for other aspectsof the disclosure.

What is claimed is:
 1. A method for processing a metadata event in acollaborative cloud-based environment, the method comprising:monitoring, by a server of the collaborative cloud-based environment,metadata associated with each of a plurality of work items in a workspace of the collaborative cloud-based environment; detecting, by theserver of the collaborative cloud-based environment, a change in themetadata associated with a particular work item in the collaborativecloud-based environment based on the monitoring of metadata associatedwith each of the plurality of work items, the change in the metadataresulting from an action performed on the particular work item by acollaborator of the collaborative cloud-based environment; generating,by the server of the collaborative cloud-based environment, a workflowcomprising a plurality of jobs and including a set of parametersdescribing work to be executed in the collaborative cloud-basedenvironment by each job with respect to the particular work item basedon the detected change in the metadata associated with the particularwork item; and distributing, by the server of the collaborativecloud-based environment, each job of the generated workflow into aparticular job queue to be processed by one or more worker machines in adistributed computing cluster associated with the collaborativecloud-based environment, the particular job queue comprising one of aplurality of job queues.
 2. The method of claim 1, further comprisingselecting, by the server of the collaborative cloud-based environment,the particular job queue based on a type of each job of the plurality ofjobs in the generated workflow, wherein the jobs of the generatedworkflow comprise a plurality of different types of jobs.
 3. The methodof claim 2, wherein the particular job queue is designated for jobs of aparticular job type, and wherein the particular job queue is serviced byone or more worker machines configured to process the particular jobtype.
 4. The method of claim 1, wherein each job is performed by the oneor more worker machines processing the job.
 5. The method of claim 1,further comprising injecting, by the server of the collaborativecloud-based environment, callback information into one or more jobs ofthe generated workflow prior to distributing the job into the particularjob queue, the callback information configured to cause a worker machineto transmit notifications to the job manager system while processing thejob.
 6. The method of claim 1, further comprising injecting, by theserver of the collaborative cloud-based environment, a token into one ormore jobs of the workflow before distributing the jobs to the particularjob queue, wherein the token is used by the one or more worker machineswhen processing the job and follows any additional job requestsinitiated by the one or more worker machines, and wherein additional jobrequests received by the job manager system are not generated into jobsor distributed to job queues if the token has been received by the jobmanager more than a threshold number of times.
 7. A system comprising: aprocessor; and a memory coupled with and readable by the processor andstoring therein a set of instructions which, when executed by theprocessor, causes the processor to process a metadata event in acollaborative cloud-based environment by: monitoring metadata associatedwith each of a plurality of work items in a work space of thecollaborative cloud-based environment; detecting a change in themetadata associated with a particular work item in the collaborativecloud-based environment based on the monitoring of metadata associatedwith each of the plurality of work items, the change in the metadataresulting from an action performed on the particular work item by acollaborator of the collaborative cloud-based environment; generating aworkflow comprising a plurality of jobs and including a set ofparameters describing work to be executed in the collaborativecloud-based environment by each job with respect to the particular workitem based on the detected change in the metadata associated with theparticular work item; and distributing each job of the generatedworkflow into a particular job queue to be processed by one or moreworker machines in a distributed computing cluster associated with thecollaborative cloud-based environment, the particular job queuecomprising one of a plurality of job queues.
 8. The system of claim 7,wherein the instructions further cause the processor to select theparticular job queue based on a type of each job of the plurality ofjobs in the generated workflow, wherein the jobs of the generatedworkflow comprise a plurality of different types of jobs.
 9. The systemof claim 8, wherein the particular job queue is designated for jobs of aparticular job type, and wherein the particular job queue is serviced byone or more worker machines configured to process the particular jobtype.
 10. The system of claim 7, wherein the one or more worker machinesperform processing of each job.
 11. The system of claim 7, theinstructions further cause the processor to inject callback informationinto one or more jobs of the generated workflow prior to distributingthe job into the particular job queue, the callback informationconfigured to cause a worker machine to transmit notifications to thejob manager system while processing the job.
 12. The system of claim 7,the instructions further cause the processor to inject a token into oneor more jobs of the workflow before distributing the jobs to theparticular job queue, wherein the token is used by the one or moreworker machines when processing the job and follows any additional jobrequests initiated by the one or more worker machines, and whereinadditional job requests received by the job manager system are notgenerated into jobs or distributed to job queues if the token has beenreceived by the job manager more than a threshold number of times.
 13. Anon-transitory, computer-readable medium comprising a set ofinstructions stored therein which, when executed by a processor, causesthe processor to process a metadata event in a collaborative cloud-basedenvironment by: monitoring metadata associated with each of a pluralityof work items in a work space of the collaborative cloud-basedenvironment; detecting a change in the metadata associated with aparticular work item in the collaborative cloud-based environment basedon the monitoring of metadata associated with each of the plurality ofwork items, the change in the metadata resulting from an actionperformed on the particular work item by a collaborator of thecollaborative cloud-based environment; generating a workflow comprisinga plurality of jobs and including a set of parameters describing work tobe executed in the collaborative cloud-based environment by each jobwith respect to the particular work item based on the detected change inthe metadata associated with the particular work item; and distributingeach job of the generated workflow into a particular job queue to beprocessed by one or more worker machines in a distributed computingcluster associated with the collaborative cloud-based environment, theparticular job queue comprising one of a plurality of job queues. 14.The non-transitory, computer-readable medium of claim 13, wherein theinstructions further cause the processor to select the particular jobqueue based on a type of each job of the plurality of jobs in thegenerated workflow, wherein the jobs of the generated workflow comprisea plurality of different types of jobs.
 15. The non-transitory,computer-readable medium of claim 14, wherein the particular job queueis designated for jobs of a particular job type, and wherein theparticular job queue is serviced by one or more worker machinesconfigured to process the particular job type.
 16. The non-transitory,computer-readable medium of claim 13, wherein the one or more workermachines perform processing of each job.
 17. The non-transitory,computer-readable medium of claim 13, the instructions further cause theprocessor to inject callback information into one or more jobs of thegenerated workflow prior to distributing the job into the particular jobqueue, the callback information configured to cause a worker machine totransmit notifications to the job manager system while processing thejob.
 18. The non-transitory, computer-readable medium of claim 13, theinstructions further cause the processor to inject a token into one ormore jobs of the workflow before distributing the jobs to the particularjob queue, wherein the token is used by the one or more worker machineswhen processing the job and follows any additional job requestsinitiated by the one or more worker machines, and wherein additional jobrequests received by the job manager system are not generated into jobsor distributed to job queues if the token has been received by the jobmanager more than a threshold number of times.